Systems and methods for redeploying source code builds

ABSTRACT

Systems and methods for redeploying source code are disclosed. The method includes receiving a request for previewing redeployment of a selected source code deployment in a target environment. The request includes an identifier of the selected source code deployment and an identifier of the target environment. In addition, the method includes identifying a source code revision identifier of the selected source code deployment, and identifying a source code revision identifier of the latest source code deployment in the target environment. Based on this information, the method retrieves a list of source code revisions between the selected deployment and the latest deployment in the target environment. The retrieving is based on the source code revision identifiers of the selected source code deployment and the latest source code deployment. The method forwards the retrieved list of source code revisions to a client device for rendering on a display of the client device.

TECHNICAL FIELD

Aspects of the present disclosure are directed to source codedeployments, and in particular to redeploying source code builds incontinuous integration systems.

BACKGROUND

The developments described in this section are known to the inventors.However, unless otherwise indicated, it should not be assumed that anyof the developments described in this section qualify as prior artmerely by virtue of their inclusion in this section, or that thosedevelopments are known to a person of ordinary skill in the art.

Continuous integration (CI) is a software development practice thatrequires software developers to periodically integrate source code intoa shared repository. The shared repository is usually managed by asource code management (SCM) system (also called a revision control orversion control system) that tracks and manages source code as it iswritten and revised. The revisions (also called “commits” in Git) addedto the SCM system can be automatically deployed by a CI managementsystem into one or more environments, such as a testing environment(where the source code is tested to ensure it runs), a stagingenvironment (where behavior of the source code is tested with realisticdata) and/or a production environment (also known as a live environmentas users directly interact with the source code in this environment).

It will be appreciated that each source code repository typicallyinclude hundreds if not thousands of commits that are constantly beingupdated and deployed and it is often difficult to track the commits theenvironments in which they have been successfully deployed.

SUMMARY

According to some embodiments of the present disclosure, acomputer-implemented method is disclosed. The method includes receiving,from a client device, a request for previewing redeployment of aselected source code deployment in a target environment. The request caninclude an identifier of the selected source code deployment and anidentifier of the target environment. The method further includesidentifying a source code revision identifier of the selected sourcecode deployment and identifying a source code revision identifier of thelatest source code deployment in the target environment. In addition,the method includes retrieving a list of source code revisions betweenthe selected source code deployment and the latest source codedeployment in the target environment. The retrieving is done based onthe source code revision identifiers of the selected source codedeployment and the latest source code deployment. The method alsoincludes forwarding the retrieved list of source code revisions to theclient device for rendering on a display of the client device.

According to some other embodiments of the present disclosure, acomputer system is disclosed. The computer system includes a processorand non-transitory memory. The non-transitory memory includesinstructions, which when executed by the processor cause the computersystem to perform a number of steps including receiving, from a clientdevice, a request for previewing redeployment of a selected source codedeployment in a target environment. The request includes an identifierof the selected source code deployment and an identifier of the targetenvironment. In addition, the steps include identifying a source coderevision identifier of the selected source code deployment andidentifying a source code revision identifier of the latest source codedeployment in the target environment. The steps also include retrievinga list of source code revisions between the selected source codedeployment and the latest source code deployment in the targetenvironment. The retrieving may be done based on the source coderevision identifiers of the selected source code deployment and latestsource code deployment. Further, the steps include forwarding theretrieved list of source code revisions to the client device forrendering on a display of the client device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a network environment in whichaspects of the present disclosure may be implemented.

FIG. 2 is a flowchart illustrating an example method for deployingsource code revisions according to some aspects of the presentdisclosure.

FIG. 3 is an example deployment history user interface.

FIG. 4 is another example deployment history user interface for aparticular environment.

FIG. 5 is an example deployment pipeline user interface.

FIG. 6 is a flowchart illustrating an example method for redeploying asource code revision from a deployment history user interface.

FIG. 7 is a flowchart illustrating an example method for generating aredeployment preview user interface.

FIG. 8 is an example redeployment preview user interface.

FIG. 9 is a flowchart illustrating an example method for redeploying asource code revision from a deployment pipeline user interface.

FIG. 10 is a block diagram illustrating a computer system, which may beused to implement various embodiments.

While the invention is amenable to various modifications and alternativeforms, specific embodiments are shown by way of example in the drawingsand are described in detail. It should be understood, however, that thedrawings and detailed description are not intended to limit theinvention to the particular form disclosed. The intention is to coverall modifications, equivalents, and alternatives falling within thespirit and scope of the present invention as defined by the appendedclaims.

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, numerousspecific details are set forth to provide a thorough understanding ofthe present invention. It will be apparent, however, that the presentinvention may be practiced without these specific details. In someinstances, well-known structures and devices are shown in block diagramform to avoid unnecessary obscuring.

In the description below, Git (and Bitbucket® offered by Atlassian,Inc.) are used as an example SCM system for illustrative purposes. Gitis a version control system used for software development and otherversion control tasks. A Git working directory is a repository that hascomplete history and revision tracking metadata and functions. It willbe appreciated that the various feature and techniques described hereincould, with appropriate modifications, be used with alternative SCMsystems (e.g., Mercurial® and Subversion®).

Further, one example CI management system in which features of thepresent disclosure may be implemented is Bitbucket Pipelines, which iscommercially available from Atlassian. Bitbucket Pipelines is integratedwith Bitbucket (Atlassian's SCM system). In the description below,Bitbucket Pipelines is used as an example CI management system andBitbucket is used as an example SCM system for illustrative purposes. Itwill be appreciated that the various feature and techniques describedherein could, with appropriate modifications, be used with alternativeCI management systems and SCM systems (e.g., TravisCl, Wercker,Buildkite, Bamboo, and Jenkins)

Source code typically progresses through four stages—development,testing, staging and production. As the name suggests, in thedevelopment stage, the source code is developed and often pushed to anSCM system. Generally speaking, developers work on the source codelocally, often updating it multiple times before pushing the latestupdated version of the source code to the SCM system. Each source codeupdate is called a ‘commit’ in Git.

Once the latest source code commit is pushed to the SCM system, ittypically passes to the testing stage (either automatically in the caseof CI or manually) where various tests are run on the source code toferret out any errors or bugs in the source code. Typically, the sourcecode is tested in all the environments (e.g., operating systems,programs, devices) it will ultimately be deployed in. Upon passing thetesting phase, the source code revision enters the staging process—wherethe behavior of the source code is tested with realistic data. When thesource code passes all these stages, it enters the production stage,also known as the live stage, where customers can interact directly withthe source code.

As noted previously, continuous integration (CI) is the practice ofmerging working copies of source code from multiple software developersinto a shared repository periodically and then using a CI managementsystem to automatically test and/or deploy the updated source code inone or more deployment environments that correspond to three of thesoftware development stages—testing, staging and production.

Developers often utilize CI/CD pipelines to automate this process.Generally speaking, a CI/CD pipeline automates software deliveryprocess—in essence, it builds committed code, and then deploys the codein different environment in a staged fashion. When source code issuccessfully deployed in one environment, it can be automatically ormanually deployed to the next environment. Developers create an initialpipeline deployment script/descriptor, which is used by the CI/CD systemto deploy the source code in various different environments.

In complex and/or large computer applications, the source code iscontinuously being developed and updated to add new features or correctpreviously offered features where errors were detected. Accordingly, atany given time, hundreds if not thousands of source code revisions maybe deployed in pipelines, making it is difficult for developers toknow/remember which source code revision is currently in which stage ofsoftware development.

To address one or more of the above-mentioned deficiencies associatedwith conventional CI management, co-pending U.S. patent application Ser.No. 16/457,451, titled “Systems and Methods for tracking source codedeployments” discloses systems and methods for creating source codedeployment pipelines and tracking source code deployments in thepipelines. In particular, the systems and methods disclosed therein wereconfigured to track deployment history for each environment.Furthermore, the systems and methods were configured to generatedashboards and/or user interfaces allowing developers to reviewdeployment history they may be interested in, promote source code fromone environment to another, and view further information about eachdeployment.

Further still, for each deployment, U.S. patent application Ser. No.16/457,451 discloses systems and methods for retrieving and renderingcorresponding information from external systems, such as issue trackingsystems, to supplement the existing deployment information. For example,the system may retrieve and render a list of issues (e.g., bugs andtheir fixes maintained by an issue tracking system such as Ere). U.S.patent application Ser. No. 16/457,451 is incorporated herein in itsentirety.

Such CI/CD pipelines and deployment tracking systems enable developersto keep a track of source code deployments. In some cases, however, adeveloper may deploy a particular source code revision to one or moreenvironments before realizing that there was a bug in the source code,an error in the deployment script, or an error in the environment,because of which the source code did not deploy correctly in aparticular environment. In such cases it is often desirable to roll backthe deployment to a previous version, for example, a version of thesource code that did not have the bug or re-run the deployment once thedeployment script is corrected.

Conventionally, if bugs were discovered in the source code once it hadbeen deployed, developers would need to fix the bug and create/commencea new build pipeline with a new version of the source code (that is bugfree), which usually takes a long time. Alternatively, developers couldrevert the changes made to the source code (which introduced the bug)and again commence a new build pipeline with the reverted source code.In another technique, a new pipeline could be created with a previoussource code revision identifier.

In all three previously known techniques, a new build pipeline needs tobe created and commenced from the beginning, which can be timeconsuming. Further, because a new pipeline is created, the deploymentartifacts (i.e., the artefacts generated at each deployment stage/step)also need to be rebuilt. Artifacts are files that are produced by aparticular deployment step, such as reports, clean copies of the sourcecode, and/or result files that are to be shared with the next step inthe build configuration. Rebuilding artifacts reduces confidence in therollback as rebuilding can produce a different artifact to the onepreviously produced, e.g., due to dependency version changes.

Aspects of the present disclosure provide a system and method torollback a failed deployment step within a build pipeline withoutcreating/commencing a new build pipeline. In particular, aspects of thepresent disclosure allow users to redeploy a previous source coderevision in a particular environment without the need to restart theentire build pipeline or create a new build pipeline. In this manner,previously created artifacts can be reused. This considerably reducesthe time taken to fix a broken environment and increases the reliabilityin the rollback.

As used in this disclosure, a build refers to a pipeline includingmultiple steps or deployments, whereas a deployment refers to aparticular step of the build that is executed in a particularenvironment.

FIG. 1 illustrates a networked infrastructure 100 in which aspects ofthe present disclosure are implemented. The infrastructure 100 includesone or more client devices 102, a source code management (SCM) system104, a CI management system 106, and a tracking system 108. In someembodiments, the networked infrastructure 100 may further include one ormore external systems that include information pertaining to sourcecode. An example of such an external system is an issue tracking system(ITS) 114 (depicted in FIG. 1). The client devices 102, SCM system 104,CI management system 106, tracking system 108 and issue tracking system114 communicate with each other over one or more communication networks110.

Generally, the systems depicted in FIG. 1 communicate with each other toupdate source code, deploy source code updates or redeploy source code,track these deployments and render dashboards displaying informationabout deployments/redeployments of interest to users.

In particular, the SCM system 104 stores source code repositories 112(hereinafter referred to as repositories 112) and manages their content.It also receives/responds to requests from client devices 102 and the CImanagement system 106 to retrieve/store data in the repositories 112.For example, the SCM system 104 may notify the CI management system 106when a user commits/pushes an update to source code in a repository 112.In addition, the SCM system 104 may receive a request from the CImanagement system 106 to access source code from a repository 112 thathas recently been updated. The SCM system 104, in response, may retrievethe requested source code and forward it to the CI management system106.

The repositories 112 may include multiple versions of source code filesand associated metadata. Often a particular repository may store sourcecode files corresponding to a particular software application and/orsoftware development team. Typically, the SCM system 104 stores andmanages multiple repositories; however, not all repositories may beregistered for CI (i.e., to have their source code verified when sourcecode is updated/revised).

To differentiate the repositories registered for CI from the rest of therepositories, in one embodiment, the metadata associated with arepository includes an indicator indicating whether CI is enabled ornot. The metadata of CI enabled repositories may also include adeployment descriptor, which includes, among other things, the steps forperforming builds/executing deployments on the source code in differentenvironments, and identifiers of the environments in which the sourcecode is supposed to be built. The CI management system 106 (as describedin detail below) may be configured to determine whether CI is requiredfor a repository by inspecting the CI indicator in the metadata and, ifsuch an indicator is present, retrieve the associated deploymentdescriptor.

The client devices 102 are configured to communicate with the SCM system104, the CI management system 106, and the tracking system 108. To thatend, in certain embodiments, the client devices 102 include variousinstalled applications such as an SCM client (not shown), a CI client(not shown) and/or a tracking client (not shown).

The SCM client may be configured to create local working copies ofsource code; modify the working copies; commit/push changes made in theworking copies to the SCM system 104 (so that the changes are written tothe relevant repository 112); fetch (e.g. pull) files from a repository112 the developer has access to; provide a user interface forreading/writing source code and deployment descriptor.

The CI client may be configured to allow communication between theclient device 102 and the CI management system 106. For example, it mayallow a developer to register an SCM repository 112 for CI with the CImanagement system 106.

The tracking client may be utilized to, for example, view/track historyof source code deployments (or pipelines) executed by the CI managementsystem 106, promote specific source code revisions in a pipeline fromone environment to another, redeploy source code in a particularenvironment, view summary of source code revisions along with any issuesassociated with that particular revision, etc.

In certain embodiments, instead of one or more of these dedicatedclients, the client device 102 simply includes a web browser client thatcommunicates with the SCM system 104, the CI management system 106,and/or the tracking system 108 via the web browser client.

Only two client devices (102A and 102B) have been illustrated, butnormal operation typically involves many more client devices connectedto the various other systems in FIG. 1.

The client devices 102 may communicate with the other systems ininfrastructure 100 via suitable communication networks 110. For example,the client devices 102 may communicate with the SCM system 104 viaprivate or public networks, and with the CI management system 106 andthe tracking system 108 via public networks. It will be appreciated thatbased on the required implementation, any suitable communication network110 may be utilized to allow communication between the systems inenvironment 100.

As described in detail below, the CI management system 106 managesbuilds and deployments. Specifically, the CI management system 106detects whether source code in a repository 112 that is registered forcontinuous integration is updated, retrieves the correspondingdeployment descriptor from the repository 112, initializes one or morecontainers to retrieve the updated source code from the repository 112and deploys the updated source code based on the deployment descriptor.The CI management system 106 also releases the containers once thedeployment is complete.

To deploy source code in various environments, the CI management system106 utilizes one or more computing resources. In some embodiments, theCI management system 106 communicates with a container management system(such as Amazon Web Services EC2 Container Services, Google Kubernetes,etc.) 116 to provision one or more computing resources to perform thebuilds. Alternatively, the CI management system 106 utilizes dedicatedon-premises computing resources (not shown) operatively connected to theCI management system 106.

A container management system 116 may be utilized when the CI managementsystem 106 services a large number of clients or software developmentteams, constantly updating the source code they are working on. Physicalon-premises devices may be utilized for lower volumes—i.e., when the CImanagement system 106 services a small number of clients or softwaredevelopment teams that update their source code infrequently.

The tracking system 108 receives/retrieves information related to sourcecode deployments from the CI management system 106 and stores thisinformation in a database, such as in the deployment database 118 shownin FIG. 1. Further, it is configured to forward this information toclient devices 102 as and when deployment information is requested bydevelopers and other interested parties, such as project managers, ITsupport, etc. The information may be communicated to the interestedparties via any known communication means such as email, SMS, instantmessage. Alternatively, the information is made accessible on a webserver, which the interested parties can access through dedicatedclients or web browsers on their client devices 102.

In addition, the tracking system 108 is configured to receive userinputs from the tracking clients to rollback a deployment in aparticular environment, instruct the CI management system to perform therollback, receive information related to the rolled back deployment (oralso referred to as a redeployment in this disclosure), and forward theredeployment information to the client devices 102 as and whenredeployment information is requested.

The issue tracking system (ITS) 114 manages work items or “issues”.Example ITSs include Jira and Jira Service Desk, which are commerciallyavailable from Atlassian. When implemented in a software developmentscenario, the work items managed by the ITS may be bugs, fixes, currentsoftware features under development, and/or features intended forfurther development. Accordingly, users may utilize the ITS 114 toidentify one or more bugs in a particular source code revision,recommend possible solutions to identified bugs, recommend features fornew versions of a source code, etc.

In order to create and progress issues in the ITS 114 users interactwith appropriate user interfaces provided (e.g., by an ITS client notshown in FIG. 1). For example, a user may create a new issue and providerelevant information in respect of the issue (e.g. the unique identifierof the source code revision the issue is associated with, a descriptionof the issue, a priority, and any other relevant information cateredfor). The ITS 114 itself typically generates an issue key that can beused to uniquely identify the issue, which may be hidden from or visibleto the user. Once an issue has been created, a user can interact withit, for example by adding additional information to the issue (e.g. inan issue description or other field), changing the state of the issue(e.g. from in progress to resolved), assigning the issue to anotherperson (e.g. by changing an assigned person field).

In certain embodiments, the tracking system 108 is configured tocommunicate with the ITS 114 to retrieve issues related to the sourcecode deployments managed by the CI management system 106. Thereafter,the tracking system 108 may store this information in the deploymentdatabase 118 and/or communicate as a summary of issues along withdeployment summary for display on a client device 102.

In FIG. 1 the SCM system 104, CI management system 106, tracking system108, and ITS system 114 have been depicted as separate systemscommunicating over one or more networks 110. These systems (or theirfunctionality) may, however, be divided over any number of physicalsystems communicating in any appropriate manner By way of example, thefunctionality of the CI management system 106 and the tracking system108 may be combined and hosted as a single system.

FIG. 2 is a flowchart illustrating an example method 200 for deployingsource code revisions in different environments using one or more of thesystems described with reference to FIG. 1. This method is describedwith respect to a single source code deployment. However, it will beappreciated that in actual implementation, the method is scaled tomultiple deployments.

At step 202, the CI management system 106 determines that a source coderepository maintained by the SCM system 104 has been updated. In certainembodiments, the CI management system 106 polls the SCM system 104 atregular intervals (e.g., every 10 minutes) to identify repositories thathave been updated in that interval. In other embodiments, the CImanagement system 106 automatically receives source code updatenotifications from the SCM system 104 when a repository is updated,e.g., because a user has pushed a new source code revision to therepository or has manually requested that a particular source coderevision be deployed.

A notification, polled for or automatically received, may becommunicated as an event descriptor to the CI management system 106. Theevent descriptor includes information about the repository 112 where thechange originated (e.g., a repository ID, a repository name, arepository type, and/or a repository URL), a unique identifier for thesource code revision (commonly referred to as a commit ID), a list ofchanges made to the source code between the previous update and thisupdate, and the names of author(s) and/or user(s) that made the changes.

In SCM systems, branching is a technique whereby developers can divergefrom the main line of source code development and continue to updatesource code without affecting the source code in the main line/branch(often called master in Git-based systems). When a source code update ispushed/committed to a branch, the event descriptor also includes anidentifier for the branch on which the source code was pushed.

An example event descriptor is illustrated in Table A below. Although atable has been used to illustrate information received in the eventdescriptor, the relevant information need not be received in a table andcould be received in any appropriate format (e.g. a simple text file, aJSON file, an XML file).

TABLE A Example event descriptor Repository 347abcef38764 ID RepositoryJohn_Doe/bamboo-bootcamp Name Repositoryhttps://api.bitbucketorg/2.0/repositories/ URL John_Doe/bamboo-bootcampAuthor John_Doe Branch Master CommitID7a273a067efbf16ec83d885ad79a7a626f2eec3f Changes  {   ″forced″: false,  ″old″: {    ″links″: {     ″commits″: {      ″href″:″https://api.bitbucketorg/2.0/repositories/     Jdoe/demo2/commits/master″     },     ″self″: {      ″href″:″https://api.bitbucketorg/2.0/repositories/     Jdoe/demo2/refs/branches/master″     },     ″html″: {      ″href″:″https://bitbucketorg/Jdoe/demo2/branch/      master″     }    },   ″type″: ″branch″,    ″target″: {     ″hash″:    ″3c62dce565729e8dda3651557d86be6380a03445″,     ″links″: {     ″self″: {       ″href″:″https://api.bitbucket.org/2.0/repositories/Jdoe/demo2/commit/3c62dce565729e8dda3651557d86be6380a03445″      },      ″html″: {      ″href″: ″https://bitbucketorg/Jdoe/demo2/commits/3c62dce565729e8dda3651557d86be6380a03445″      }     },     ″author″: {     ″raw″: ″John Doe″,      ″user″: {       ″username″: ″Jdoe23″,      type″: ″user″,       ″uuid″: ″{39846whedwqh49873}″,      }     }   },

In certain embodiments, the SCM system 104 communicates the eventdescriptor via a webhook—an HTTP POST callback that creates and passesthe event descriptor to the CI management system 106 when acorresponding repository is updated. For this to work, webhooks arecreated for the repositories 112 registered for CI.

Once an event descriptor that corresponds to a repository for which CIis required is received, the CI management system 106 retrieves thedeployment descriptor for the repository at step 204. In certainembodiments, the deployment descriptor may be stored in the SCMrepository 112 along with the source code, whereas in other embodiments,the deployment descriptor may be stored in the CI management system 106.Accordingly, depending on the particular embodiment, the CI managementsystem 106 retrieves the deployment descriptor from the correspondingSCM repository 112 or from memory associated with the CI managementsystem 106.

Generally speaking, the deployment descriptor corresponding to aparticular repository includes instructions for deploying source coderevisions from that repository 112 in one or more environments. Further,in some cases, the deployment descriptor may include different sets ofdeployment instructions for different source code branches. For example,if a repository includes a master branch and a testing branch, thedeployment descriptor may include one set of instructions for deployingsource code revisions committed to the master branch and another set ofinstructions for deploying source code revisions committed to thetesting branch.

Further still, the deployment descriptor may include a different set ofinstructions for deploying source code revisions that are manuallyselected by a developer for a custom deployment.

It will be appreciated that these are merely examples and that in somecases the deployment descriptor may include a single set of instructionsfor deploying source code revisions committed/pushed on any branchand/or manually selected.

A set of deployment instructions may include the name of one or morerepository branches for testing and steps for executing the deploymentfor each branch. The steps include commands for executing the deploymentand settings of a container in which the source code is supposed to bedeployed.

In addition, for each step, the deployment descriptor may include a stepname, a container image of the container required for the deployment, atrigger, a deployment environment, a script, and/or an artifact. Table Billustrates an example deployment descriptor.

TABLE B Deployment descriptor Build configuration Default Step 1 Name:Build and test Image: node: 8.5.0 deployment testing Script: npm installnpm test npm build Artifacts “dist/**” Step 2 Name: Deploy to stagingImage: Python:3.5.1 Deployment: staging Trigger: manual Script: pythondeploy.py staging Step 3 Name: Deploy to production Image: Python:3.5.1Trigger: manual Deployment: production Script: python deply.py prod

In the above example, the deployment descriptor includes the followinginformation:

A deployment configuration. In this example, the deploymentconfiguration is ‘default’ which means that the steps for thisconfiguration are executed for all commits (or source code revisionspushed to the SCM system 104) for that repository, unless the commit isfor a particular branch or is manually selected. In other examples, thebuild configuration may point to a particular ‘branch’, in which casethe steps are executed when a source code revision is committed to thedefined branch. Alternatively, this field could be ‘custom’, in whichcase the steps are executed when a source code revision is manuallyselected for deployment (e.g., via the web interface).

Steps, which define the commands executed and settings of containers inwhich the source code is to be built. Each step in the deploymentdescriptor may correspond to a particular step in the deploymentpipeline. Each step may further include the following fields:

Name, which defines what the step is doing. This field is usuallydisplayed by the tracking system 108 and therefore is usually somethingthat developers can easily understand.

Image: this specifies the container image (e.g., Docker image) to beused for executing a particular step. If an image is not specified, adefault image may be used.

Trigger: this specifies whether a particular step is manual orautomatic—i.e., whether the CI management system 106 shouldautomatically run the step or wait for approval.

Deployment: defines the type of environment for the deployment (e.g.,testing, staging or production).

Script: this field contains a list of commands that are executed toperform the build.

Artifacts: this field defines files that are produced by a particularstep, such as reports, clean copies of the source code, and/or resultfiles that are to be shared with the next step in the buildconfiguration.

Although the deployment descriptor is illustrated in a table, therelevant information need not be stored in a table and could be storedin any appropriate format (e.g. a text file such as YAML file).

To retrieve data, such as the deployment descriptor and source code,from the SCM repository 104, the CI management system 106 may negotiatepermissions with the SCM system 104. For example, when a user firstregisters their repository for CI, the user authorizes the CI managementsystem 106 to retrieve information such as source code and deploymentdescriptor from the SCM repository without the need for explicitpermissions when the CI management system 106 requires this information.This authorization may be done using any commonly knownauthorization/permissions techniques or standards, such as OAuth.

According to the OAuth standard, the CI enabled repositories 112 sharesecrets with the CI management system 106. Based on these secrets, theCI management system 106 generates authorization tokens when it executesa deployment for a repository. The tokens may be valid for thedeployment duration and may expire once the deployment is complete.

Thus, using an authorization token, the CI management system 106 canaccess the SCM repository 112 identified in the event descriptor andretrieve the deployment descriptor.

In some embodiments, the deployment descriptor is temporarily stored inthe CI management system 106 to be utilized during the deployment. Oncethe deployment is completed, the deployment descriptor is discarded.Alternatively, they are stored in the CI management system 106 forfuture deployments.

Returning to FIG. 2, at step 206, the CI management system 106determines whether deployment is required. To this end, the CImanagement system 106 compares the source code revision informationprovided in the event descriptor with the build configurationinformation in the deployment descriptor. In particular, it may comparethe identifier of the branch onto which the source code revision waspushed with the build configuration field in the deployment descriptor.

If the comparison results in a negative—e.g., if the branch identifierin the event descriptor does not match the branch identifier in thedeployment descriptor or there is no default build configuration in thedeployment descriptor, the CI management system 106 may determine thatthere is no need for deployment and the method 200 ends.

Alternatively, if the comparison results in a positive—e.g., if thebranch identifier in the event descriptor matches the branch identifierin the deployment descriptor or there is a default build configurationin the deployment descriptor, the CI management system 106 may determinethat the source code revision needs to be deployed and the method 200proceeds to step 208 where the CI management system 106 executes one ormore steps in the deployment descriptor.

In order to execute the deployment, the CI management system 106generates a deployment request. The deployment request may be createdbased on the event descriptor and deployment descriptor. Largely, thedeployment request includes an identifier that uniquely identifies thecurrent deployment, authorization tokens for accessing a repository(i.e., the repository identified in the event descriptor), and a fieldindicating the deployment environment (e.g., testing, staging orproduction). The deployment request may further include a repositoryidentifier, an image identifier, and a commit identifier. In someembodiments, the deployment request may further include a fieldindicating the steps that are to be performed during the deployment.

Table C illustrates an example deployment request below. Although atable has been used to illustrate this information, the relevantinformation need not be stored in a table and could be stored in anyappropriate format (e.g. a simple text file, a JSON file, an XML file,etc.).

TABLE C deployment request Deployment 8374 ID Auth-token fd4jw4908343943Deployment Staging Repository 347abcef38764 ID Commit ID fd78cd23 ImageNode: 8.5.0 Script Python deply.py staging

In the above example, the deployment request includes the followinginformation:

A unique deployment ID associated with that deployment request.

An Auth-token for accessing the repository in which the source coderevision is stored.

The environment to which the deployment is being made (‘Deployment’)

Repository identifier of the repository where the source code revisionis stored.

The Commit ID of the commit that was pushed or manually selected forwhich the deployment is to be executed

Build steps (‘Script’) retrieved from the deployment descriptor thatinclude the commands for executing that particular deployment step.

The CI system 106 retrieves some of the required information, such asthe repository ID from the event descriptors and the build steps fromthe deployment descriptor. Other information (such as the deploymentidentifier and the authorization token) may be generated by the CImanagement system 106. Once a deployment request is created, it isqueued for execution.

Next, the CI management system 106 retrieves the queued deploymentrequest and executes it. Typically this is done by launching acontainer, retrieving the source code revision from the SCM system 104,executing the build steps, capturing the output of the deployment anddeleting the container.

Upon commencing the execution of the deployment, the CI managementsystem 106 is configured to update the status of the deployment based onthe result. It is configured to communicate information about thedeployment to the tracking system 108 at step 210. In certainembodiments, this information may include the deployment ID, thecorresponding commit ID, repository ID, an identifier of the user thatrequested the deployment (e.g., either by pushing the source coderevision into the SCM repository or by manually selecting a particularsource code revision for deployment), the date and time the deploymentwas executed, the environment in which the source code revision wasdeployed, and status of the deployment (e.g., “in progress”). The CImanagement system 106 then updates the status once the deployment iscomplete (to “success” of “failed” for instance). Status of thedeployment includes, e.g., whether the deployment is queued/pending, inprogress, completed, successful or unsuccessful. When the deploymentrequest is first created, the status of the deployment is set asqueued/pending. This status is updated during the deployment process.For example, when the deployment is initiated, the status is updated to‘in progress’ and once it is completed the status may be updated to‘completed’, ‘successful’ or ‘unsuccessful’ (depending on the outcome ofthe deployment). Further, the CI management system 106 stores anyartifacts created as part of the deployment in a suitable internaldatabase. These artifacts may be used to redeploy a build in aparticular environment and in some cases to deploy the build in asubsequent environment.

Information about the deployment may be forwarded to the tracking system108 in the form of a tracking descriptor. Table D illustrates an exampledeployment tracking descriptor below. Although a table has been used toillustrate information stored in the deployment tracking descriptor, therelevant information need not be stored in a table and could be storedin any appropriate format (e.g. a simple text file, a JSON file, an XMLfile, etc.).

TABLE D tracking descriptor Deployment 8374 ID Repository ID347kdsfjh38764 Commit ID 7a273a067efbf16ec83d885ad79a7a626f2eec3f UserID John_Doe Date 19 June 2018 09:06:30 Environment Testing Status inprogress

The CI management system 106 may retrieve some of the requiredinformation for this descriptor, such as the repository ID, commit ID,and user ID from the event descriptor. Other information such as thedeployment ID is retrieved from the deployment request and the date andenvironment may be retrieved once the deployment is completed. Further,the status of the deployment can be retrieved from the CI managementsystem 106.

The tracking system 108 stores the information received in the trackingdescriptor in the deployment database 118 at step 212 to be used wheninformation about the deployment is requested.

As described previously, the tracking system 108 communicates with theCI management system 106 to receive data about deployments and withclient devices 102 to present deployment information to users. Forexample, a user may access the tracking system 108 via the trackingclient and may request the tracking system 108 to display status ofdeployments in a particular repository, in a particular environmentand/or request the tracking system 108 to present detailed informationabout a single deployment.

To generate user interfaces that provide this type of information, thetracking system 108 stores deployment tracking information in thedeployment database 118 for various repositories. To this end, thetracking system 108 first receives deployment information from the CImanagement system 106. In some embodiments, the CI management system 106may be configured to provide this information in the form of trackingdescriptors (see table D) to the tracking system 108 wheneverdeployments are queued and/or completed. In other cases, the trackingsystem 108 may be configured to poll the CI management system 106periodically to determine if any deployment descriptor are available.

In any case, the tracking system 108 receives deployment information forqueued and executed deployments from the CI management system 106. Thisinformation is stored in the deployment database 118.

An example of a data structure storing deployment information isillustrated in table E below. Although a table is used to illustrate thedata structure, the relevant information need not be stored in a tableand could be stored in any appropriate format.

TABLE E Example tracking information data structure Deployment BuildCommit ID ID. ID Repository ID Name Date User ID Env. . . . . . . . . .. . . . . . . . . 333 101 7778e48 3 Build and test June 19, John_DoeTesting vvvvvvvvvv47kd 2018 sfjh3876 302  38 3846hfd 4478frhjksdf8Deploy to staging June 18, Jane_Deer Staging 2018 298 100 F89dsh4347kdsfjh3876 Add Bitbucket June 3, Suzie_Mclean Production client repoto 2018 submodules 297  37 58973hf 4478frhjksdf8 Update Docker June 3,Ryan_Gosming Testing compose to remove 2018 breaking code 288 100F89dsh4 347kdsfjh3876 Add Bitbucket May 27, Suzie_Mclean Staging clientrepo to 2018 submodules . . . . . . . . . . . . . . . . . .

Further, although the data structure shows deployments corresponding todifferent repositories, in some embodiments, the tracking system maymaintain different tracking data structures for different repositories,such that one data structure only includes deployment information for asingle repository. In addition, the tracking information data structuremay include a field indicating the status of each deployment.

It will be appreciated that a particular deployment pipeline may includemultiple steps—such as ‘deploy to test’ and if successful ‘deploy tostaging’. The deployment in each stage may be stored as a separaterecord in the database 118 with its own unique deployment ID. ‘Build ID’or ‘build #’ on the other hand may correspond to a particular pipelineand therefore may be the same for different steps. In the example above,the database stores two deployments with IDs 298 and 288 for the samesource code revision and repository. In this case, although thedeployment IDs are different, the build IDs are the same.

As noted previously, the tracking system 108 may receive variousdifferent types of requests from client devices 102 to view deploymentinformation. In one example, a developer may wish to view a list ofrecent deployments made for a particular repository. In another example,a developer may wish to view a deployment pipeline for a particularsource code revision. In each of these cases the tracking system 108generates and forwards a suitable user interface for rendering on theclient device 102. The user interface generated in response to a requestof the first example is a deployment history user interface and the userinterface generated in response to the request of the second example isa deployment pipeline user interface.

In order to request a deployment history user interface, a user may openthe CI management client or the tracking client on their client device102. This action causes the client device 102 to generate and forward atracking information request to the tracking system 108. The trackinginformation typically includes information required by the trackingsystem 108 to service the request and may vary depending on the type ofrequest. At the very least, it includes an identifier of the repositoryassociated with the developer. In addition to this, it may include otherinformation. For example, if the user wishes to view deployments in aparticular environment or just view the most recent deployments in eachenvironment, the tracking information request may further include theenvironment ID of the environment the user wishes to view or a limit onthe number of deployments to retrieve from each environment. Thetracking request may further include a user identifier of the user ofthe client device 102

Using the repository identifier, the tracking system 108 retrieves alist of latest deployments for that repository from the deploymentdatabase 118. The number of deployments retrieved in the list may beconfigurable. For example, the tracking information request may includea field indicating the number of requested records (e.g., 20 latestdeployments) for that repository.

This list of records (along with corresponding deployment information)is forwarded to the requesting client device 102 for rendering on adisplay of the client device. FIG. 3 illustrates an example deploymenthistory dashboard 300 rendered by a client application (e.g., trackingclient) on the client device 102. Generally speaking, the dashboard 300includes a summary of the latest deployments in the repositoryassociated with the user accessing the dashboard 300. In particular, inthis example, the dashboard 300 includes a deployment history section302, which includes information about the latest deployments (arrangedin date order such that the latest deployment is displayed on top). Eachrow in the history section 302 may display information about aparticular deployment including the build number 304, the commit ID 306,a description 308, the environment in which it was deployed 310, date ofthe deployment 312, and an identifier of the user 314 that caused thedeployment. Status 315 of each deployment (e.g., completed orin-progress) may also be displayed in the history section 302.

The dashboard 300 further includes one or more filtering controls 316 tofilter the deployments based on one or more information fields of thedeployments, such as the environment, date range, the author, etc. Thisallows the developer to view selected deployments, for example,deployments pertaining to a particular environment, deploymentstriggered by a particular user 314, deployments made within a certaindate range, etc. FIG. 3 illustrates three filtering controls, ‘test’,‘staging’ and ‘production’ to filter deployment history based ondeployment environments.

Further, the dashboard 300 may include a section showing the latestdeployment in each environment. In FIG. 3 this is displayed in the formof user interface cards 318, 320 and 322.

FIG. 4 shows a user interface 400 that is displayed when a user selectsone of the filtering controls 316 of dashboard 300 (in particular thetest environment filtering control 316).

As seen in this dashboard, the deployment history section is updated toreveal the latest deployments in the test environment. In this case,build numbers 331-338 have been deployed in the test environmentrecently. Of these deployments, build number 332 and 335 have notsuccessfully been deployed whereas the others have been successfullydeployed.

In addition to the usual information about each deployment, thedeployment history section 402 also provides one or more selectableaffordances 404 to perform one or more auxiliary actions on thedisplayed deployments. In the example shown in FIG. 4, the selectableaffordance is in the form of ellipses. Selection of the selectableaffordance 404 causes a dropdown menu with available actions to bedisplayed. In certain embodiments, one of the auxiliary actions is aredeploy action, which causes a particular deployment to be redeployedin the given environment. In other examples, instead of a dropdown menu,the auxiliary functions may be provided by individual selectable buttonson the particular deployment. For example, one or more deployments mayinclude a selectable icon for requesting a redeployment.

In other cases, instead of wishing to view deployment history in aparticular environment, the user may wish to view a particulardeployment pipeline—e.g., to check which environments it has alreadybeen deployed in, which environments it needs to be deployed in, etc.

FIG. 5 shows an example deployment pipeline user interface 500. In thisexample, the user interface 500 shows details about build #334. Card 502illustrates key information about the source code revision, includingthe commit ID 504, description 506, time since the build was deployed508, and the date on which it was deployed.

Card 510 shows the steps of the deployment pipeline. In this case, thebuild, test, and staging steps have been completed whereas theproduction step still need to be performed. That is, the build hasalready been deployed in the test and staging environments but has yetto be deployed to the production environment.

From the deployment pipeline user interface 500, a developer (if he/shehas the required permissions) may be able to deploy a source coderevision in a particular environment and/or redeploy a particular sourcecode revision in an environment. As shown in card 510, the userinterface 500 provides a selectable affordance 514 to deploy build #333in the production environment and a selectable affordance 516 toredeploy build #333 in the staging environment.

Accordingly, there may be at least two mechanisms by which a source coderevision can be redeployed in a particular environment—either via thedeployment history user interface 400 or via the deployment pipelineinterface 500.

In the following sections, example methods for redeploying a deploymentin a given environment are discussed. Suppose for a particular sourcecode, the current deployment in the staging environment is deploymentbuild #100 and a developer identifies a bug in the source codecorresponding to build #100. The developer may decide to roll back thedeployment in the staging environment to a previous deployment, e.g.,build #98 (which didn't have this specific bug) until the developer canfind a solution to fix the identified bug. The example methods describedhere can be used to perform such rollbacks/redeployments.

In particular, the example method described with reference to FIG. 6 canbe used to redeploy a source code revision from the deployment historyuser interface 400 whereas the method described with reference to FIG. 9can be used to redeploy a source code revision from the deploymentpipeline user interface 500.

Method 600 (shown in FIG. 6) commences at step 602 when a client devicemakes a request for a deployment history user interface. In one example,a user operating on a client device 102 can request the tracking system108 to display the deployment history in a particular environment (e.g.,testing environment) for a particular repository. To this end, theclient device and in particular the tracking client operating on theclient device creates a tracking request including at least a useridentifier of the user making the request, a repository identifier ofthe repository associated with the user, and an identifier of theselected environment type.

The tracking system 108 receives the tracking request, and based on thereceived repository identifier and environment identifier retrieves thelatest deployments for the selected repository in the selectedenvironment from tracking database 118 at step 603.

Next, at step 604, the tracking system determines whether one or more ofthe retrieves deployments can be redeployed. In some implementations,any deployment that has previously been deployed in an environment(successfully or not) may be redeployed in that environment. In othercases, only deployments that have already successfully been deployed inan environment can be redeployed in that environment. Further still, asredeployments use the artifacts that were created when the build wasoriginally deployed to that environment, the artifact needs to beavailable for the build to be redeployed.

Accordingly, in some embodiments, at step 604, for each of the retrieveddeployments, the tracking system 108 determines the status of thedeployment in the selected environment (e.g., based on information inthe tracking database 118). The deployments that were not successfullydeployed in that environment are discarded. For the remainingdeployments, the tracking system 108 determines whether artifacts exist.To this end, the tracking system 108 may send a request for artifactinformation to the CI management system 106. The request includesdeployment identifiers of the successful builds. The CI managementsystem 106 may perform a lookup for the artifacts corresponding to thereceived deployment identifiers. If corresponding artifacts are found,the CI management system 106 may communicate a confirmation.Alternatively if corresponding artifacts are not found for one or moreof the deployments the CI management system 106 may communicate anegative message.

Based on the response from the CI management system 106, the trackingsystem 108 may further cull the list of deployments that can beredeployments.

Once the tracking system has determined which deployments can beredeployed, if it determines that at least one deployment isredeployable, the tracking system 108 communicates the list of thelatest deployments in the selected repository and environment identifiedat step 602 along with their corresponding information to the clientdevice at step 606. Further, for the deployments that were determined tobe candidates for redeployment at step 604, the tracking system 108communicates that redeployment is possible at this step. In someexamples, this communication may be in the form of a flag—a value ofTRUE indicating that redeployment is possible for the correspondingdeployment and a value of FALSE indicating that redeployment is notpossible.

Based on the information received from the tracking system 108, theclient device renders the deployment history user interface. In someexamples, this user interface may be similar to user interface 400.Further, in the rendered user interface, for the deployments that can beredeployed, a “redeploy” selectable affordance 404 may be enabled. Forthe deployments that cannot be redeployed (e.g., because they were notsuccessfully deployed in the first instance and/or their correspondingartifacts no longer exist in the CI management system database), theselectable affordance may be disabled. In case the redeployment optionis presented as part of a drop-down menu, for the deployments whereredeployment is not possible, this option is not displayed.

Next, at step 608, a determination is made whether redeployment requesthas been made with respect to a deployment displayed in the deploymenthistory user interface 500. In one example, the user may select adeployment from the displayed deployment history (e.g., build #336) forredeployment (e.g., by selecting a corresponding selectable affordance)in the selected environment (e.g., testing environment). In this case,the tracking client creates a redeployment request including the buildnumber of the selected deployment and the selected environmentidentifier and forwards the redeployment request to the tracking system108.

If the tracking system 108 receives such a redeployment request, themethod 600 proceeds to step 610, where the tracking system 108 generatesa preview user interface of the redeployment and communicates thepreview user interface to the tracking client for display on the userdevice 102. As the name suggests, the preview user interface shows apreview of the consequences of performing the redeployment. Inparticular, it may show a list of commit identifiers that will bereversed if the selected deployment is redeployed. In addition, in somecases, the preview may depict a list of issue tracking system issuesthat will be reverted in case the deployment is redeployed.

In essence, the developer may review the preview user interface anddetermine whether the developer still wishes to proceed with theredeployment.

At step 612 a determination is made whether the developer wishes tocontinue with the redeployment. In one example, the preview userinterface may include a further selectable affordance to confirmredeployment. If the user selects this affordance, the tracking clientsends a confirmation message back to the tracking system 108 indicatingthat the developer wishes to continue.

If at step 612 a confirmation messages is received at the trackingsystem 108, the method proceeds to step 614 where the tracking system108 instructs the CI management system 106 to rerun the selecteddeployment. The request may include the commit ID associated with thedeployment, the original deployment identifier and/or the buildidentifier.

Once the CI management system 106 receives the redeployment request, itqueues the redeployment request for execution. It also retrieves theartifact corresponding to that build step and stores it along with thedeployment request. It may also generate a tracking descriptor andupdate the status of the deployment in the tracking descriptor to“pending”. In some examples, the original deployment descriptorassociated with the original deployment is updated. In other examples,the CI management system 106 may generate a new deployment descriptor.In case a new deployment descriptor is generated, the deploymentidentifier may be different from the original deployment descriptor, butthe remaining information in the tracking descriptor may be the same.The tracking descriptor is forwarded to the tracking system 108. Thetracking system 108 in turn communicates the status of the redeploymentrequest to the client device based on the status of the deploymentreceived in the tracking descriptor. The tracking client in turn mayupdate the status of the deployment in the deployment history userinterface to indicate that the redeployment is pending.

Subsequently, the CI management system 106 re-executes the deploymentwith the retrieved artifact. In one example, the CI management system106 re-executes the deployment using the process described withreference to step 208 of FIG. 2.

After the source code revision is redeployed, the CI management system106 may update the status of the deployment in the tracking descriptorfrom “pending” to “successful” or “unsuccessful”. This notification iscommunicated to the tracking system 108, at step 616, which forwards thecommunication to the client device 102 and stores the updated trackingdescriptor in its own database. The tracking client in turn updates thestatus of the deployment in the deployment history user interface toindicate whether the build has been successfully redeployed or whetherthe redeployment attempt has been unsuccessful. In one example, thestatus notification for indicating successful redeployment is differentfrom the status notification for indicating successful deployment sothat a user can easily distinguish between deployments and redeploymentsin the user interface.

Returning to step 604, if at this step the tracking system 108determines that none of the latest deployments for the selectedenvironment are redeployable, the tracking system 108 communicates thelist of the latest deployments in the selected repository andenvironment identified at step 602 along with their correspondinginformation to the client device at step 618. As no redeployment ispossible in this situation, the method 600 ends after this step.

Further, returning to steps 608 and 612, if a redeployment request orconfirmation is not received, e.g., because the user did not select theoption to redeploy a source code revision from the deployment history UI400 or failed to confirm redeployment from the preview UI, the method600 ends.

As described with reference to method step 610, the tracking system 108generates a preview user interface upon receiving a redeployment requestfrom a tracking client. In order to generate this preview userinterface, the tracking system 108 may collect further information aboutthe deployment from external systems (e.g., the SCM system 104 and/orthe ITS 114).

FIG. 7 illustrates an example method 700 for generating this previewuser interface. The method commences at step 702, where the trackingsystem 108 retrieves a list of source code revisions that exist betweenthe latest deployment in the selected environment and the deploymentselected for redeployment and/or changes in the source code between thetwo deployments from the SCM system 104.

As described previously, developers usually work locally on their sourcecode and may update source code locally in the SCM client multiple times(by ‘committing’ the source code locally) before ‘pushing’ the sourcecode to the SCM system 104. Similarly, developers may commit a number ofupdates to the source code on a particular branch, e.g., a developmentbranch, before pushing the updates onto the master branch (which is thebranch on which deployments are executed). Accordingly, there may be anumber of undeployed and deployed source code revisions between thelatest deployment in the selected environment and the selectedredeployment.

At step 702, the tracking system 108 retrieves information about theseintervening source code revisions from the SCM system 104. To this end,the tracking system 108 retrieves the commit IDs corresponding to thedeployment selected by the developer for redeployment and the latestdeployment in that environment. For example, in the deployment historyUI shown in FIG. 4, if the user selects build #336, the tracking system108 retrieves the commit ID corresponding to that build number—i.e.,commit ID d24c24f. It also identifies the latest deployment in thatenvironment—i.e., build #338 and retrieves the commit ID correspondingto that deployment—i.e., commit ID 0719e3a.

At step 704, the tracking system 108 requests the SCM system 104 toprovide a list of commit IDs corresponding to source code revisions thatexist between the two commit IDs. Further, it may request the SCM system104 to provide a list of changes in the source code that occurredbetween the two commit IDs.

The requested information (i.e., the list of commit IDs and/or thechanges in source code between the two commit IDs) is received at thetracking system 108 at step 706.

Next, in certain embodiments, where the environment 100 includes an ITS114 for managing issues related to software development, the trackingsystem 108 requests the ITS 114 to forward one or more issues related tothe commit IDs received at step 706 and/or related to the commit IDsforwarded to the SCM at step 704. The request includes the list ofcommit IDs.

The ITS 114 compares the list of commit IDs with commit IDs of issuesmanaged by the ITS 114 (e.g., by performing a lookup of the commit IDsin a commit ID field of the issues maintained by the ITS 114).

If the ITS 114 identifies any issues corresponding to the receivedcommit IDs, it forwards a summary of the identified issues to thetracking system 108, which at step 710, receives the summary of theissues. The summary may include, for example, a description of theissue, status of the issue (resolved, pending, etc.), author of theissue, the related commit ID, and any other such relevant information.

At step 712, the information received from the external sources (e.g.,the list of commit IDs, updates to the source code between the twodeployments, and/or the issues associated with the source code betweenthe two deployments) is forwarded to the client device 102 for renderingin the preview user interface.

FIG. 8 is a screenshot illustrating an example preview user interface800 including a number of tabs 802, 804, and 806, each displaying adifferent aspect of the particular redeployment (i.e., redeployment#336). In particular, tab 802 illustrates a list of commits (3 in thiscase) between deployments 336 and 338 in the testing environment. If theselected source code revision is redeployed in the testing environment,802 shows the list of commits that will be affected and will beeffectively “undeployed” from the environment. In addition to the commitID, the tab 802 displays a name/description of the commit. In someembodiments, tab 802 may also display the author of the commit.

The developer may toggle between tabs 802-806 to change the displayedinformation. For instance, if tab 804 is selected, differences in sourcecode between the two deployments may be displayed. If the selectedsource code revision is redeployed in the testing environment, tab 804illustrates the source code lines that would essentially be “undeployed”from the environment. Further, if tab 806 is selected, a summary of theissues related to any of the commit ID between deployments 336 and 338may be displayed. If the selected source code revision is redeployed inthe testing environment, tab 806 illustrates the issues that would beaffected by the redeployment.

This way a developer is made aware of the issues that may arise if thatparticular source code revision is promoted to the next developmentstage.

The user interface 800 further includes one or more controls 808, 810 totrigger a promotion from one environment to another. In the example UI800, one control may be a dragging action to drag build #336 to thetesting card 318. Another control may be the ‘redeploy’ affordance 810located at the bottom right corner of the user interface 800.

In addition to allowing users to redeploy deployment 336 to the testingenvironment, UI 800 may also include indication of the latest deploymentin the testing environment (e.g., build #338 in this example UI).

It will be appreciated that FIG. 8 illustrates an example preview UI forobtaining user approval to redeploy a source code revision. The trackingclient may be configured to render any other types of UIs for obtainingthis approval. For instance, the tracking client may present a dedicatedpage for redeployments that lists a number of deployments available forredeployment. A user may be able to select multiple redeployments (notin the same environments obviously) from such a UI. Alternatively, theclient application may notify users of available redeployment bydisplaying an alert or pop-up window (e.g., in dashboard 400 or 500) viawhich the user may be able to trigger a redeployment.

FIG. 9 is a flowchart illustrating an example method for redeploying asource code revision in a selected environment from a deploymentpipeline user interface. The method commences at step 902 where arequest for rendering a deployment pipeline user interface is receivedat the tracking system 108. In one example, a user operating on a clientdevice 102 can request the tracking system 108 to display the deploymentpipeline interface (e.g., UI 500) for a particular source code revisionpipeline in a particular repository. To this end, the client device 102and in particular the tracking client operating on the client devicecreates a tracking request including at least a user identifier of theuser making the request, a repository identifier of the repositoryassociated with the user, and an identifier of the selected buildnumber.

The tracking system 108 receives the tracking request, and based on thereceived repository identifier and build number retrieves the trackingdescriptors corresponding to the build number from tracking database 118at step 903. For instance, the tracking system 108 may retrieve trackingdescriptors for that build in the testing environment, in the stagingenvironment and in the product environment.

Next, at step 904, the tracking system 108 determines whether any of thedeployments in the pipeline can be redeployed. This is similar to step604 of FIG. 6 and therefore is not described in detail here again.

Once the tracking system 108 has determined which deployments can beredeployed, it communicates the list of the deployments in the selectedpipeline along with their corresponding information to the clientdevice. Further, for the deployments that were determined to becandidates for redeployment at step 904, the tracking system 108communicates that redeployment is possible at this step. In someexamples, this communication may be in the form of a flag—a value ofTRUE indicating that redeployment is possible for the correspondingdeployment and a value of FALSE indicating that redeployment is notpossible.

Based on the information received from the tracking system 108, theclient device renders the deployment pipeline user interface. In someexamples, this user interface may be similar to user interface 500.Further, in the rendered user interface, for the deployments that can beredeployed, a “redeploy” selectable affordance may be enabled. For thedeployments that cannot be redeployed (e.g., because they were notsuccessfully deployed in the first instance and/or their correspondingartifacts no longer exist in the CI management system database), theselectable affordance may be disabled.

Next, at step 908, a determination is made whether redeployment requesthas been made with respect to a deployment displayed in the deploymenthistory user interface 500. In one example, the user may select adeployment from the pipeline (e.g., deployment in staging environment)for redeployment (e.g., by selecting a corresponding selectableaffordance). In this case, the tracking client creates a redeploymentrequest including the deployment identifier of the selected deployment(e.g., build number and environment) and forwards the redeploymentrequest to the tracking system 108.

The tracking system 108 then generates a redeployment preview interfacesimilar to the interface 800 at step 910 and the remainder of method 900is similar to the method steps 610-618 of FIG. 6 and therefore are notrepeated here again.

In the embodiments described above, the tracking system 108 determinesthat redeployment is possible based on the previous deployment statusand whether a previously created artifact is still available at the CImanagement system 106. In some other embodiments, the tracking system108 may also determine whether the user viewing the deployment historyinterface in method 600 or the deployment pipeline interface in method900 has permission to request redeployment. In some cases, not alldevelopers associated with a given software application may havepermission to redeploy a corresponding build. In other cases, somedevelopers may only have permission to redeploy in certain environments(e.g., testing), but not other environments (e.g., production). Thepermissions can be set globally for all deployments or they can be setindividually for each environment such that different developers havedifferent sets of permissions in different environments. Thesepermissions may be stored in the CI management system and/or the SCMsystem 104. Accordingly, in some cases, the tracking system 108 mayforward the user identifier received as part of the tracking request tothe CI management system 106 and/or the SCM system 104 to determinewhether the user has permission to promote any of the deployments to bedisplayed on the corresponding user interface. If the user does not havepermission to redeploy any deployments, the redeploy selectableaffordance is disabled. Alternatively, if the user has permission toredeploy any of the deployments, and the other conditions forredeployment are also met, the corresponding redeploy selectableaffordances may ne enabled.

Further still, in other embodiments, the check to determine whetherredeployment is possible may not be performed before rendering thecorresponding user interface. Instead, this check may be performed whena user selects a particular redeploy affordance and a redeploy requestis received at the tracking system 108. If it is determined at thisstage that redeployment is possible, the redeployment preview UI may bedisplayed. Alternatively, if it is determined that redeployment is notpossible (e.g., because initial source code version wasn't successfullydeployed in that environment, corresponding artefact has expired or userdoesn't have permission), an error message may be returned to thetracking client, which renders the error message on the client device102. In this alternative embodiment, the tracking system 108 only needsto perform this check if redeployment is requested and even then only ofthe requested deployment, which reduces unnecessary calls between thetracking system 108 and the CI management system 106 or SCM system 104.

The operations/techniques described herein are implemented by one ormore special-purpose computing systems or devices. For example, innetworked infrastructure 100: SCM system 104 may be provided by acomputer system; the client devices 102 are computer systems; the CImanagement system 106 is provided by one or more computer systems; thetracking system 108 is provided by one or more distributed computingsystems, and the computing resources on the cloud computing platform 116are also provided by one or more computer systems.

A special-purpose computing system may be hard-wired to perform therelevant operations. Alternatively, a special-purpose computing systemmay include digital electronic devices such as one or moreapplication-specific integrated circuits (ASICs) or field programmablegate arrays (FPGAs) that are persistently programmed to perform therelevant operations. Further alternatively, a special-purpose computingsystem may include one or more general purpose hardware processorsprogrammed to perform the relevant operations pursuant to programinstructions stored in firmware, memory, other storage, or acombination.

A special-purpose computing system may also combine custom hard-wiredlogic, ASICs, or FPGAs with custom programming to accomplish therelevant operations described herein. A special-purpose computing systemmay be a desktop computer system, a portable computer system, a handhelddevice, a networking device or any other device that incorporateshard-wired and/or program logic to implement relevant operations.

By way of example, FIG. 10 provides a block diagram that illustrates oneexample of a computer system 1000 upon which embodiments of theinvention may be implemented. Computer system 1000 includes a bus 1002or other communication mechanism for communicating information, and ahardware processor 1004 coupled with bus 1002 for processinginformation. Hardware processor 1004 may be, for example, a generalpurpose microprocessor, a graphical processing unit, or other processingunit.

Computer system 1000 also includes a main memory 1006, such as a randomaccess memory (RAM) or other dynamic storage device, coupled to bus 1002for storing information and instructions to be executed by processor1004. Main memory 1006 also may be used for storing temporary variablesor other intermediate information during execution of instructions to beexecuted by processor 1004. Such instructions, when stored innon-transitory storage media accessible to processor 1004, rendercomputer system 1000 into a special-purpose machine that is customizedto perform the operations specified in the instructions.

Computer system 1000 further includes a read only memory (ROM) 1008 orother static storage device coupled to bus 1002 for storing staticinformation and instructions for processor 1004. A storage device 1010,such as a magnetic disk or optical disk, is provided and coupled to bus1002 for storing information and instructions.

In case the computer system 1000 is the client device 102, the computersystem 1000 may be coupled via bus 1002 to a display 1012 (such as anLCD, LED, touch screen display or other display), for displayinginformation to a computer user. An input device 1014, includingalphanumeric and other keys, may be coupled to the bus 1002 forcommunicating information and command selections to processor 1004.Another type of user input device is cursor control 1016, such as amouse, a trackball, or cursor direction keys for communicating directioninformation and command selections to processor 1004 and for controllingcursor movement on display 1012.

According to one embodiment, the techniques herein are performed bycomputer system 1000 in response to processor 1004 executing one or moresequences of one or more instructions contained in main memory 1006.Such instructions may be read into main memory 1006 from another storagemedium, such as a remote database. Execution of the sequences ofinstructions contained in main memory 1006 causes processor 1004 toperform the process steps described herein. In alternative embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions.

The term “storage media” as used herein refers to any non-transitorymedia that stores data and/or instructions that cause a machine tooperate in a specific fashion. Such storage media may comprisenon-volatile media and/or volatile media. Non-volatile media includes,for example, optical or magnetic disks, such as storage device 1010.Volatile media includes dynamic memory, such as main memory 1006. Commonforms of storage media include, for example, a floppy disk, a flexibledisk, hard disk, solid state drive, magnetic tape, or any other magneticdata storage medium, a CD-ROM, any other optical data storage medium,any physical medium with patterns of holes, a RAM, a PROM, and EPROM, aFLASH-EPROM, NVRAM, any other memory chip or cartridge.

Storage media is distinct from but may be used in conjunction withtransmission media. Transmission media participates in transferringinformation between storage media. For example, transmission mediaincludes coaxial cables, copper wire and fiber optics, including thewires that comprise bus 1002. Transmission media can also take the formof acoustic or light waves, such as those generated during radio-waveand infra-red data communications.

Computer system 1000 also includes a communication interface 1018coupled to bus 1002. Communication interface 1018 provides a two-waydata communication coupling to a network link 1020 that is connected tothe communication network 110. For example, communication interface 1018may be an integrated services digital network (ISDN) card, cable modem,satellite modem, etc. As another example, communication interface 1018may be a local area network (LAN) card to provide a data communicationconnection to a compatible LAN. Wireless links may also be implemented.In any such implementation, communication interface 1018 sends andreceives electrical, electromagnetic or optical signals that carrydigital data streams representing various types of information.

Computer system 1000 can send messages and receive data, includingprogram code, through the network(s) 110, network link 1020 andcommunication interface 1018. In case the computer system hosts the CImanagement system 106, the computer system 1000 may receive an eventnotification from the SCM system 104 via the network 110, network link1020, and communication interface 1018. The received event notificationmay be executed by processor 1004 as it is received, and/or stored instorage device 1010, or other non-volatile storage for later execution.

As described previously, the computer system 1000 as described above maybe configured in a plurality of useful arrangements. In one arrangement,the computer system 1000 is a server computer (such as a computer systemhosting the CI management system 106) comprising one or morenon-transitory computer-readable data storage media stored with one ormore sequences of instructions/software modules which when executedcause the computer to perform the operations/techniques that aredescribed herein.

Some aspects of the present disclosure are described with respect tothree deployment environments—testing, staging, and production. However,the systems and methods disclosed herein are not limited to threeenvironments or just these environments. Instead, in someimplementations, source code revisions may be deployed in multipledifferent environments (e.g., multiple testing environments, and/ormultiple production environments). Which environments a particular buildis meant to be deployed in can be defined in the deployment descriptor.

In the foregoing specification, embodiments of the invention have beendescribed with reference to numerous specific details that may vary fromimplementation to implementation. Thus, the sole and exclusive indicatorof what is the invention, and is intended by the applicants to be theinvention, is the set of claims that issue from this application, in thespecific form in which such claims issue, including any subsequentcorrection. Any definitions expressly set forth herein for termscontained in such claims shall govern the meaning of such terms as usedin the claims. Hence, no limitation, element, property, feature,advantage or attribute that is not expressly recited in a claim shouldlimit the scope of such claim in any way. The specification and drawingsare, accordingly, to be regarded in an illustrative rather than arestrictive sense.

As used herein the terms “include” and “comprise” (and variations ofthose terms, such as “including”, “includes”, “comprising”, “comprises”,“comprised” and the like) are intended to be inclusive and are notintended to exclude further features, components, integers or steps.

Various features of the disclosure have been described using processsteps. The functionality/processing of a given process step couldpotentially be performed in various different ways and by variousdifferent systems or system modules. Furthermore, a given process stepcould be divided into multiple steps and/or multiple steps could becombined into a single step. Furthermore, the order of the steps can bechanged without departing from the scope of the present disclosure.

It will be understood that the embodiments disclosed and defined in thisspecification extends to alternative combinations of two or more of theindividual features mentioned or evident from the text or drawings.These different combinations constitute various alternative aspects ofthe embodiments.

The invention claimed is:
 1. A computer-implemented method, the methodcomprising: receiving, from a client device, a request to display adeployment history of a target environment; in response to the request,obtaining a list of a previous deployments associated with a repositoryidentified in the request; analyzing the list of previous deployments toidentify a subset of previous deployments that is redeployable in thetarget environment; causing display of at least a portion of the subsetof previous deployments that is redeployable on a display of the clientdevice; in response to a user selection of a displayed elementassociated with a particular previous deployment that is redeployable inthe target environment, causing display of a preview user interface onthe client device, the preview user interface including a listing of oneor more items to be reverted in response to rolling back to theparticular previous deployment; and in response to a user selection of aselectable affordance displayed on the client device, causing a rollback of a current code deployment to the particular previous deploymentin the target environment.
 2. The computer-implemented method of claim1, wherein the list of one or more items to be reverted in response torolling back to the particular previous deployment in the targetenvironment comprises one or more issues associated with rolling backfrom the current code deployment in the target environment to theparticular previous deployment in the target environment.
 3. Thecomputer-implemented method of claim 2, wherein the one or more issuesassociated with rolling back from the current code deployment in thetarget environment to the particular previous deployment in the targetenvironment are identified based on a list of source code revisionsbetween one or more source code revision identifiers associated with theparticular previous deployment in the target environment and one or moresource code revision identifiers associated with the current codedeployment in the target environment.
 4. The computer-implemented methodof claim 1, wherein analyzing the list of previous deployments toidentify the subset of previous deployments that is redeployable in thetarget environment comprises determining whether an artifactcorresponding to a deployment of the list of previous deployments thathas been successfully deployed in the target environment is available.5. The computer-implemented method of claim 1, wherein analyzing thelist of previous deployments to identify the subset of previousdeployments that is redeployable in the target environment comprisesdetermining whether a user has a permission to redeploy or roll back adeployment of the list of previous deployments in the targetenvironment.
 6. The computer-implemented method of claim 1, furthercomprising: upon determining that the particular previous deployment isnot redeployable in the target environment, communicating an errormessage to the client device for displaying on the client device.
 7. Thecomputer-implemented method of claim 1, further comprising: receiving arequest for tracking information from the client device, the request fortracking information including an identifier of a deployment pipeline;retrieving a list of source code deployments for the deployment pipelinefrom a deployment database based on the identifier of the deploymentpipeline; and forwarding the retrieved list of source code deploymentsfor the deployment pipeline to the client device for display in adeployment pipeline user interface on the client device.
 8. A computersystem comprising: a processor; non-transitory memory, thenon-transitory memory comprising instructions, which when executed bythe processor cause the computer system to: receive, from a clientdevice, a request to display a deployment history of a targetenvironment; in response to the request, obtain a list of a previousdeployments associated with a repository identified in the request;analyze the list of previous deployments to identify a subset ofprevious deployments that is redeployable in the target environment;cause display of at least a portion of the subset of previousdeployments that is redeployable on a display of the client device; inresponse to a user selection of a displayed element associated with aparticular previous deployment that is redeployable in the targetenvironment, cause display of a preview user interface on the clientdevice, the preview user interface including a listing of one or moreitems to be reverted in response to rolling back to the particularprevious deployment; and in response to a user selection of a selectableaffordance displayed on the client device, cause a roll back of acurrent code deployment to the particular previous deployment in thetarget environment.
 9. The computer system of claim 8, wherein the listof one or more items to be reverted in response to rolling back to theparticular previous deployment in the target environment comprises oneor more issues associated with rolling back from the current codedeployment in the target environment to the particular previousdeployment in the target environment.
 10. The computer system of claim8, wherein the one or more issues associated with rolling back from thecurrent code deployment in the target environment to the particularprevious deployment in the target environment are identified based on alist of source code revisions between one or more source code revisionidentifiers associated with the particular previous deployment in thetarget environment and one or more source code revision identifiersassociated with the current code deployment in the target environment.11. The computer system of claim 8, wherein to analyze the list ofprevious deployments to identify the subset of previous deployments thatis redeployable in the target environment, the non-transitory memoryfurther comprising instructions, which when executed by the processorcause the processor to: determine whether an artifact corresponding to adeployment of the list of previous deployments that has beensuccessfully deployed in the target environment is available.
 12. Thecomputer system of claim 8, wherein to analyze the list of previousdeployments to identify the subset of previous deployments that isredeployable in the target environment, the non-transitory memoryfurther comprising instructions, which when executed by the processorcause the processor to: determine whether a user has a permission toredeploy or roll back a deployment of the list of previous deploymentsin the target environment.
 13. The computer system of claim 8, whereinthe non-transitory memory further comprising instructions, which whenexecuted by the processor cause the processor to: upon determining thatthe particular previous deployment is not redeployable in the targetenvironment, communicate an error message to the client device fordisplaying on the client device.
 14. The computer system of claim 8,wherein the non-transitory memory further comprising instructions, whichwhen executed by the processor cause the processor to: receive a requestfor tracking information from the client device, the request fortracking information including an identifier of a deployment pipeline;retrieve a list of source code deployments for the deployment pipelinefrom a deployment database based on the identifier of the deploymentpipeline; and forward the retrieved list of source code deployments forthe deployment pipeline to the client device for display in a deploymentpipeline user interface on the client device.
 15. A non-transitorycomputer-readable media (CRM) comprising instructions, which whenexecuted by a processor of a computing device, causes the computingdevice to perform operations comprising: receiving, from a clientdevice, a request to display a deployment history of a targetenvironment; in response to the request, obtaining a list of a previousdeployments associated with a repository identified in the request;analyzing the list of previous deployments to identify a subset ofprevious deployments that is redeployable in the target environment;causing display of at least a portion of the subset of previousdeployments that is redeployable on a display of the client device; inresponse to a user selection of a displayed element associated with aparticular previous deployment that is redeployable in the targetenvironment, causing display of a preview user interface on the clientdevice, the preview user interface including a listing of one or moreitems to be reverted in response to rolling back to the particularprevious deployment; and in response to a user selection of a selectableaffordance displayed on the client device, causing a roll back of acurrent code deployment to the particular previous deployment in thetarget environment.
 16. The non-transitory CRM of claim 15, wherein thelist of one or more items to be reverted in response to rolling back tothe particular previous deployment in the target environment comprisesone or more issues associated with rolling back from the current codedeployment in the target environment to the particular previousdeployment in the target environment.
 17. The non-transitory CRM ofclaim 16, wherein the one or more issues associated with rolling backfrom the current code deployment in the target environment to theparticular previous deployment in the target environment are identifiedbased on a list of source code revisions between one or more source coderevision identifiers associated with the particular previous deploymentin the target environment and one or more source code revisionidentifiers associated with the current code deployment in the targetenvironment.
 18. The non-transitory CRM of claim 15, wherein foranalyzing the list of previous deployments to identify the subset ofprevious deployments that is redeployable in the target environment, theoperations further comprise: determining whether a user has a permissionto redeploy or roll back a deployment of the list of previousdeployments in the target environment; and determining whether anartifact corresponding to a deployment of the list of previousdeployments that has been successfully deployed in the targetenvironment is available.
 19. The non-transitory CRM of claim 15,wherein the operations further comprise: upon determining that theparticular previous deployment is not redeployable in the targetenvironment, communicating an error message to the client device fordisplaying on the client device.
 20. The non-transitory CRM of claim 15,wherein the operations further comprise: receiving a request fortracking information from the client device, the request for trackinginformation including an identifier of a deployment pipeline; retrievinga list of source code deployments for the deployment pipeline from adeployment database based on the identifier of the deployment pipeline;and forwarding the retrieved list of source code deployments for thedeployment pipeline to the client device for display in a deploymentpipeline user interface on the client device.